Graphics Plus/Graphics Plus.iso/amiga/gui/x/xfig.lha/src/x11/Doc/TODO

Text File | 1993-07-26 | 9.3 KB | 172 lines

This file contains some possible things to do in future versions of xfig.

allow rotated boxes (not just polygons)
reduce number of grid lines (if necessary) when zooming < 1.0
fix grid rounding problems at 0.75 zoom factor
allow printing of grid in figure
make the rulers understand the real screen resolution according to the server
add the concept of "layers" for each depth.  That way a user may work on
    certain layers at one time, masking out or overlaying the other layers
    as desired.
make <Shift>middle mouse button DELETE previous points just created during
    create POLYobject/ARC/Ellipse etc.  That way, one may backup when
    creating objects.
create resource for "print" command (e.g. lp, lpr, whatever) which uses meta-
    notation to place filename (e.g.  print_command: "lpr -P%p %f" where %p
    is the printer string and %f is the filename)
make line counter update correctly when reading multiple-line POLYLINES and
    SPLINES from input file
allow vertically-aligned text
  "top" would mean the insertion point specifies the line over the top of the
        text
  "middle" would mean that it specifies the midline of the text (I'm not
        sure how this is defined, perhaps the average of top and base
        or top and bottom.
  "base" would mean the line under all letters which do not hang down.
        For example, g and j extend below the baseline.
  "bottom" would mean the time under the bottom of the text including
        descenders.
have arc sub-type 2 for pie wedge-type arcs
have common edit popup for all four splines to allow conversion between all
save modified_flag before file operations and restore if undo used
Should arrow size change in update mode when linewidth changes?
investigate whether eps objects that don't have a preview bitmap
    are scaled correctly
change eps_bitmaps so that background is transparent (needs to work
    in normal and reverse-video modes).
Make popup windows come up so that they don't overlap the figure (if possible).
    An edit popup window should at least not overlap the
    object being edited (again only if possible).
Use fill pattern (grey-shading) to mimic color objects on monochrome systems.
Extend smart links to work for SCALE, MOVEPT and perhaps EDIT, UPDATE.
    Could also extend them to work for arc-type links and for
    ellipse/circle objects and objects inside compound objects.
    Also, at the moment smart-links
    only work for one end of a link if both ends of the link
    happen to touch the object being operated on.  To fix this would
    require changing the F_linkinfo structure to have left_endpt,
    left_prevpt, right_endpt, right_prevpt fields instead of the current
    endpt, prevpt and two_pts fields.
Make xfig resources more consistent with normal use of resources in X clients.
    e.g. provide support to allow each command button (say) to be
    a different color.  Ditto for mode buttons, etc.
investigate if we should be setting initialResourcesPersistent to false for
    widgets that are created and destroyed as required.
Still need to think about how point positioning should be utilized with
    many of the editing commands, e.g. if point positioning is set to
    large grid and you are trying to move an object, should:
    a) it be ignored, b) you can pick up an object anywhere but
    you must put the 'pick-up' point back on a grid posn,
    c) you have to pick up and put down objects at grid posns,
    d) you can pick up and place an object anywhere but when you
    place it, the point on the object closest the pickup point is
    automatically rounded to the nearest grid posn, e) you can
    pick up objects anywhere and movement is multiples of the grid size.
    The current behaviour is c) and b) can be mimicked by changing the
    point posn indicator mid-move.  It has the disadvantage that you
    may not be able to pick up an object which isn't on the grid points.
    I think e) is the next best but it won't let you mimick b).
Use clipping rectangles in more places:
    use the redisplay_* routines as necessary.
allow popup menus to be pinned?
have a resource which can be set to keep backups during a save, instead of
    prompting the user about overwrite etc.
make a keypad label:
    This should popup in the mousefun window whenever a panel for
    entering text is entered.  The kbd_ic icon is already there.
zooming of text is still a kludge. (It doesn't work properly yet)
make arcs use pw_curve to speed them up.
add bounding box to every F_object definition, useful for:
    1) faster drawing of rubber objects
    2) handling the selective redrawing of figures better after they become
       the innocent victim during an expose or erasure of another object
things like pan/zoom/resize/iconify will still leave junk on the screen
    or mess up the figure if you are in the middle of drawing it:
    One solution is to call canvas_rightbut_proc whenever the
    action_on flag is set and one of the above functions is called.
    This forces the operation being performed to be cancelled - probably
    not a good idea for panning - we might be trying to pan a little
    bit to place the last point in a large object.
    Another solution is to have a big case statement which performs
    a single elastic draw of whatever object is being drawn/moved etc.
    The function would need to be called before an iconify (or
    whatever) and again after the operation was completed.  This
    would allow drawing operations to be continued after window functions
    had been performed.
    A third solution is to use a canvas_elasticdraw_save parameter
    instead of using a case statement - it would need to be set
    prior to every elastic draw operation.
Generalize align mode (like glue mode) to allow arbitrary tagged objects to be
    aligned rather than just compounds.
Additional align mode options for distributing objects evenly within a compound
    or abutting them together: abutT, abutB, abutL, abutR, distH, distV
Some facility to provide better support for small screens.
    e.g. scrollable mode button list or automatic resizing
    to have several rows as needed.  A good test is to limit the total
    space to 640x480 so that it is still useable on an IBM-PC VGA screen.
Make a raise/lower depth feature:
    the raise_ic icon is already in w_icons.c
Make xfig understand depth better:
    If you set the depth using the object edit panels, xfig will redraw
    them correctly, however it would be nice if as you entered new filled
    objects that they were automatically given an appropriate depth.
    This would involve finding the depth of all overlapping (filled?)
    objects and setting the depth to be one less.
    What about support for negative depth values?

--------------------------------------------------------------------
The following items would require a change to the Fig file protocol:
--------------------------------------------------------------------

extend color model to include 24-bit color
use floating point coordinates for objects (at least internally to xfig if not
    in the figure file)
super/subscripts for text objects
allow background color for figure and store in fig file - also requires that
    fig2dev knows about this background color
allow fractional text sizes (float)
possibly make extension to Fig protocol to handle several line
    cap/join styles (e.g. round, butt, miter)

--------------------------------------------------------------------
What really needs to be done is a major rework of the list structures used
    to store xfig objects.  Here are some comments involving the change.

-------- note about restructuring xfig data structures -------------
Rather than having a depth attribute for objects, you can use the order
in which objects are entered to determine their depth:  later objects
appear on the top.  A raise/lower depth operation would allow you to
change the ordering.

The consequences to the current implementation of converting totally to this
scheme are non-trivial.  Instead of having separate lists for each object
type, you need to have a single list which has a union of all the different
objects as its type.  This will require changes in many places in the code.
At the moment there are many places where each of the lists are traversed
separately.  In many cases the code can be simplified dramatically if there
was only a single list.  For example, to perform a move on an object there
are separate routines (one for each object type) to start/cancel/place the
object.  You could replace this by a single routine for start/cancel and
place which worked no matter what type you had.  (Who says you can't use
object-orientation in C :-)).  Another advantage is that the current caching
scheme for redrawing would no longer be needed (i.e. redrawing would be
greatly simplified).  Also undo would become simpler (I think).

If we want to make a smooth transition from the current scheme to the
one described above (and I do), here is how I propose we do it:

We need to change every direct access to the current lists to use functions.
i.e. something like
        for (a=objects.arc; a!=NULL; a=a->next) ...
to be something like
        for (a=first_arc(); a!=NULL; a=next_arc(a)) ...

At the moment these routines would be simple to implement.
Once all occurrences had been changed, it would simply be a matter
of changing the underlying list structure and changing the first_arc,
next_arc routines.  Then as we had time we could replace whichever
sets of six loops by a single loop which did
        for (o=first_obj(); o!=NULL; o=next_obj(o)) ...
-------- end of note about restructuring xfig data structures -------------